|
|
|
|
|
|
|
You can use API functions to obtain a device context for a window, but it's much easier to use the hdc property of a form or picture control to obtain its device context. |
|
|
|
|
|
|
|
|
Call Polygon(hdc, points(0), UBound(points) + 1) |
|
|
|
|
|
|
|
|
Be careful not to make any changes to the configuration of a device context obtained in this manneryou could interfere with Visual Basic's own drawing system. Either use the SaveDC and RestoreDC API functions to save and restore the current configuration of the device context or create a separate device context using the CreateCompatibleDC function. Figure S3-1 shows the result after this fix is made. |
|
|
|
|
|
|
|
|
Figure S3-1:
Second version of the Poly program |
|
|
|
|
|
|
|
|
Clearly, something is still wrong. You could look closely at the algorithm for the LoadPointArray function, but that would be a waste of time. Not that you would be wrong to suspect it, but this is, after all, an API puzzle book. Adding an ordinary Visual Basic bug would be unfair, misleading, and something I would never dream of doingthis early in the book. |
|
|
|
|
|
|
|
|
Compare Figure S3-1 with Figure P3-1. It's almost as if Figure S3-1 were a hugely magnified segment of the upper-left corner of Figure P3-1. Could we be dealing with a scaling problem? |
|
|
|
|
|
|
|
|
Absolutely. The points are generated based on the form's Height and Width properties. These properties are specified in twips1/1440 of an inch. API functions use the current logical coordinate system, which is always pixels by default. How do you convert from twips to pixels? The Screen object has a property, called TwipsPerPixelX and TwipsPerPixelY, that can be used to determine the number of twips in each pixel. Divide the height and width by the corresponding TwipsPerPixel value, as in the following code, and things are looking much better, as shown in Figure S3-2. |
|
|
|
|
|
|
|
|
LoadPointArray Width / Screen.TwipsPerPixelX, Height / _
Screen.TwipsPerPixelY, 5, points() |
|
|
|
|
|
